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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document specifies the stage 2 of the UE Positioning function of E-UTRAN, which provides the 
mechanisms to support or assist the calculation of the geographical position of a UE. UE position knowledge can be 
used, for example, in support of Radio Resource Management functions, as well as location-based services for 
operators, subscribers, and third-party service providers. The purpose of this stage 2 specification is to define the E- 
UTRAN UE Positioning architecture, functional entities and operations to support positioning methods. This 
description is confined to the E-UTRAN Access Stratum. It does not define or describe how the results of the UE 
position calculation can be utilised in the Core Network (e.g., LCS) or in E-UTRAN (e.g., RRM). 

UE Positioning may be considered as a network-provided enabling technology consisting of standardised service 
capabilities that enable the provision of location applications. The application(s) may be service provider specific. The 
description of the numerous and varied possible location applications which are enabled by this technology is outside 
the scope of the present document. However, clarifying examples of how the functionality being described may be used 
to provide specific location services may be included. 

This stage 2 specification covers the E-UTRAN positioning methods, state descriptions, and message flows to support 
UE Positioning. 
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3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in [1] apply. 

As used in this document, the suffixes '-based' and '-assisted' refer respectively to the node that is responsible for 
making the positioning calculation (and which may also provide measurements) and a node that provides measurements 
(but which does not make the positioning calculation). Thus, an operation in which measurements are provided by the 
UE to the E-SMLC to be used in the computation of a position estimate is described as 'UE-assisted' (and could also be 
called 'E-SMLC -based'), while one in which the UE computes its own position is described as 'UE-based'. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply. 

AoA Angle of Arrival 

CID Cell-ID (positioning method) 

E-SMLC Enhanced Serving Mobile Location Centre 

E-CID Enhanced Cell-ID (positioning method) 

ECEF Earth-Centered, Earth-Fixed 

ECl Earth-Centered-Inertial 

EGNOS European Geostationary Navigation Overlay Service 

E-UTRAN Enhanced Universal Terrestrial Radio Access Network 
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GAGAN GPS Aided Geo Augmented Navigation 

GLONASS GLObal'naya NAvigatsionnaya Sputnikovaya Sistema (Engl.: Global Navigation Satellite System) 

GMLC Gateway Mobile Location Center 

GNSS Global Navigation Satellite System 

GPS Global Positioning System 

LCS Location Services 

LCS-AP LCS Application Protocol 

LMU Location Measurement Unit 

LPP LTE Positioning Protocol 

LPPa LTE Positioning Protocol Annex 

MO-LR Mobile Originated Location Request 

MT-LR Mobile Terminated Location Request 

NI-LR Network Induced Location Request 

PDU Protocol Data Unit 

PRS Positioning Reference Signal 

QZSS Quasi-Zenith Satellite System 

RRM Radio Resource Management 

SBAS Space Based Augmentation System 

SET SUPL Enabled Terminal 

SEP SUPL Location Platform 

SUPL Secure User Plane Location 

Tadv Timing Advance 

UE User Equipment 

WAAS Wide Area Augmentation System 

WGS-84 World Geodetic System 1984 

4 Main concepts and requirements 

4.1 Assumptions and Generalities 

The stage 1 description of LCS at the service level is provided in [3]; the stage 2 LCS functional description, including 
the LCS system architecture and message flows, is provided in [2]. 

Positioning functionality provides a means to determine the geographic position and/or velocity of the UE based on 
measuring radio signals. The position information may be requested by and reported to a client (e.g., an application) 
associated with the UE, or by a client within or attached to the core network. The position information shall be reported 
in standard formats, such as those for cell-based or geographical co-ordinates, together with the estimated errors 
(uncertainty) of the position and velocity of the UE and, if available, the positioning method (or the list of the methods) 
used to obtain the position estimate. 

Restrictions on the geographic shape encoded within the 'position information' parameter may exist for certain LCS 
client types. The EPS, including E-UTRAN, shall comply with any shape restrictions defined in LTE and, in a 
particular country, with any shape restrictions defined for a specific LCS client type in relevant national standards. For 
example, in the US, national standard J-STD-036-B restricts the geographic shape for an emergency services LCS client 
to minimally either an "ellipsoid point" or an "ellipsoid point with uncertainty circle and confidence" as defined in [4]. 

It shall be possible for the majority of the UEs (active or inactive) within a network to use the LCS feature without 
compromising the radio transmission or signalling capabilities of the E-UTRAN. 

The uncertainty of the position measurement shall be network-implementation-dependent, at the choice of the network 
operator. The uncertainty may vary between networks as well as from one area within a network to another. The 
uncertainty may be hundreds of metres in some areas and only a few metres in others. In the event that a particular 
position measurement is provided through a UE-assisted process, the uncertainty may also depend on the capabilities of 
the UE. In some jurisdictions, there is a regulatory requirement for location service accuracy that is part of an 
emergency service. Further details of the accuracy requirements can be found in [3]. 

The uncertainty of the position information is dependent on the method used, the position of the UE within the coverage 
area and the activity of the UE. Several design options of the E-UTRAN system (e.g., size of cell, adaptive antenna 
technique, pathloss estimation, timing accuracy, eNode B surveys) shall allow the network operator to choose a suitable 
and cost-effective UE positioning method for their market. 
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There are many different possible uses for the positioning information. The positioning functions may be used internally 
by the EPS, by value-added network services, by the UE itself or through the network, and by "third party" services. 
The feature may also be used by an emergency service (which may be mandated or "value-added"), but the location 
service is not exclusively for emergencies. 

The E-UTRAN is a new radio system design without a pre-existing deployment of 'legacy' UEs operating according to 
the radio interface. This freedom from legacy equipment enables the location service feature design to make use of 
appropriate techniques to provide the most accurate results. The technique must also be a cost-effective total solution, 
must allow evolution to meet evolving service requirements, and must be able to take advantage of advances in 
technology over the lifetime of E-UTRAN deployments. 

Design of the E-UTRAN positioning capability as documented in this specification includes position methods, protocols 
and procedures that are either adapted from capabilities already supported for UTRAN and GERAN, or created 
separately from first principles. The proportion of the latter is higher than if the UTRAN and GERAN capabilities had 
been designed to provide forward compatibility to other access types. In contrast to GERAN and UTRAN, the E- 
UTRAN positioning capabilities are intended to be forward compatible to other access types and other position 
methods, in an effort to reduce the amount of additional positioning support needed in the future. This goal also extends 
to user plane location solutions such as OMA SUPL ([17], [18]), for which E-UTRAN positioning capabilities are 
intended to be compatible where appropriate. 

As a basis for the operation of UE Positioning in E-UTRAN, the following assumptions apply: 

both TDD and FDD will be supported; 

the provision of the UE Positioning function in E-UTRAN and EPC is optional through support of the specified 
method(s) in the eNode B and the E-SMLC; 

UE Positioning is applicable to any target UE, whether or not the UE supports LCS, but with restrictions on the 
use of certain positioning methods depending on UE capability (as defined within the LPP protocol); 

the positioning information may be used for internal system operations to improve system performance; 

the UE Positioning architecture and functions shall include the option to accommodate several techniques of 
measurement and processing to ensure evolution to follow changing service requirements and to take advantage 
of advancing technology; 

LMU aspects are left for implementation and are not standardized in this release. 

4.2 Role of UE Positioning IVIethods 

The E-UTRAN may utilise one or more positioning methods in order to determine the position of an UE. 
Positioning the UE involves two main steps: 

signal measurements; and 

Position estimate and optional velocity computation based on the measurements. 

The signal measurements may be made by the UE or the eNode B. The basic signals measured for terrestrial position 
methods are typically the E-UTRA radio transmissions; however, other methods may make use of other transmissions 
such as general radio navigation signals including those from Global Navigation Satellites Systems (GNSSs). 

The positioning function should not be limited to a single method or measurement. That is, it should be capable of 
utilising other standard methods and measurements, as such methods and measurements are available and appropriate, 
to meet the required service needs of the location service client. This additional information could consist of readily 
available E-UTRAN measurements. 

The position estimate computation may be made by the UE or by the E-SMLC. 

4.3 Standard UE Positioning IVIethods 

The standard positioning methods supported for E-UTRAN access are: 
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network-assisted GNSS methods; 

downlink positioning; 

enhanced cell ID method. 

Hybrid positioning using multiple methods from the list of positioning methods above is also supported. 

These positioning methods may be supported in UE-based, UE-assisted/E-SMLC -based, or eNB-assisted versions. 
Table 4.3-1 indicates which of these versions are supported in this version of the specification for the standardised 
positioning methods. 

Table 4.3-1 : Supported versions of UE positioning methods 



Method 


UE-based 


UE-assisted, E-SMLC- 
based 


eNB- 
assisted 


SUPL 


A-GNSS 


Yes 


Yes 


No 


Yes (UE- 
based and 
UE-assisted 


Downlink 


No 


Yes 


No 


Yes (UE- 
assisted) 


E-CID 


No 


Yes 


Yes 


Yes (UE- 
assisted) 



4.3.1 Network-assisted GNSS Methods 

These methods make use of UEs that are equipped with radio receivers capable of receiving GNSS signals. 

Examples of GNSS include GPS, Modernized GPS, Galileo, GLONASS, Space Based Augmentation Systems (SEAS), 
and Quasi Zenith Satelhte System (QZSS). 

In this concept, different GNSSs (e.g. GPS, Galileo, etc.) can be used separately or in combination to determine the 
location of a UE. 

The operation of the network-assisted GNSS methods is described in clause 8.1. 

4.3.2 Downlink positioning 

The downlink (OTDOA) positioning method makes use of the measured timing of downlink signals received from 
multiple eNode Bs at the UE. The UE measures the timing of the received signals using assistance data received from 
the positioning server, and the resulting measurements are used to locate the UE in relation to the neighbouring eNode 
Bs. 

The operation of the downlink positioning method is described in clause 8.2. 

4.3.3 Enlnanced Cell ID Methods 

In the Cell ID (CID) positioning method, the position of an UE is estimated with the knowledge of its serving eNode B 
and cell. The information about the serving eNode B and cell may be obtained by paging, tracking area update, or other 
methods. Enhanced Cell ID (E-CID) positioning refers to techniques which use additional UE and/or E-UTRAN radio 
resource and other measurements to improve the UE location estimate. 

Although E-CID positioning may utilise some of the same measurements as the measurement control system in the 
RRC protocol, the UE generally is not expected to make additional measurements for the sole purpose of positioning; 
i.e., the positioning procedures do not supply a measurement configuration or measurement control message, and the 
UE reports the measurements that it has available rather than being required to take additional measurement actions. 

In cases with a requirement for close time coupling between UE and eNode B measurements (e.g., TADV type 1 and 
UE Tx-Rx time difference), the eNode B configures the appropriate RRC measurements and is responsible for 
maintaining the required coupling between the measurements. The operation of the Enhanced Cell ID method is 
described in clause 8.3. 



£75/ 



3GPP TS 36.305 version 10.1.0 Release 10 



12 



ETSI TS 136 305 VI 0.1.0 (2011-04) 



5 E-UTRAN UE Positioning Architecture 

Figure 5-1 shows the architecture in EPS appHcable to positioning of a UE with E-UTRAN access. 

The MME receives a request for some location service associated with a particular target UE from another entity (e.g., 
GMLC, eNB, or UE) or the MME itself decides to initiate some location service on behalf of a particular target UE 
(e.g., for an IMS emergency call from the UE) as described in [2]. The MME then sends a location services request to 
an E-SMLC. The E-SMLC processes the location services request which may include transferring assistance data to the 
target UE to assist with UE-based and/or UE-assisted positioning and/or may include positioning of the target UE. The 
E-SMLC then returns the result of the location service back to the MME (e.g., a position estimate for the UE and/or an 
indication of any assistance data transferred to the UE). In the case of a location service requested by an entity other 
than the MME (e.g., UE, eNB, or E-SMLC), the MME returns the location service result to this entity. 

The SLP is the SUPL entity responsible for positioning over the user plane. Further details of the relationship of the 
user-plane positioning entities to the E-UTRAN control-plane positioning architecture are described in Annex B. 
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Figure 5-1 : UE Positioning Architecture applicable to E-UTRAN 



5.1 UE Positioning Operations 



To support positioning of a target UE and delivery of location assistance data to a UE with E-UTRAN access in EPS, 
location related functions are distributed as shown in the architecture in Figure 5-1 and as clarified in greater detail in 
TS 23.271 [2]. The overall sequence of events applicable to the UE, E-UTRAN and E-SMLC for any location service is 
shown in Figure 5.1-1. 

Note that when the MME receives Location Service Request in case of the UE is in ECM-IDLE state, the MME 
performs a network triggered service request as defined in TS 23.401 [19] in order to establish a signalling connection 
with the UE and assign a specific eNodeB. The UE is assumed to be in connected mode before the beginning of the 
flow shown in the Figure 5. 1-1; that is, any signalling that might be required to bring the UE to connected mode prior to 
step la is not shown. 
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Figure 5.1-1 : Location Service Support by E-UTRAN 

la. Either: the UE requests some location service (e.g. positioning or delivery of assistance data) to the serving 
MME at the NAS level. 

lb. Or: some entity in the EPC (e.g. GMLC) requests some location service (e.g. positioning) for a target UE to the 
serving MME . 

Ic. Or: the serving MME for a target UE determines the need for some location service (e.g. to locate the UE for an 
emergency call). 

2. The MME transfers the location service request to an E-SMLC. 

3a. The E-SMLC instigates location procedures with the serving eNode B for the UE - e.g. to obtain positioning 
measurements or assistance data.. 

3b. In addition to step 3a or instead of step 3a, the E-SMLC instigates location procedures with the UE - e.g. to 
obtain a location estimate or positioning measurements or to transfer location assistance data to the UE. 

4. The E-SMLC provides a location service response to the MME and includes any needed results - e.g. success or 
failure indication and, if requested and obtained, a location estimate for the UE. 

5a. If step la was performed, the MME returns a location service response to the UE and includes any needed results 
- e.g. a location estimate for the UE. 

5b. If step lb was performed, the MME returns a location service response to the EPC entity in step lb and includes 
any needed results - e.g. a location estimate for the UE. 

5c. If step Ic occurred, the MME uses the location service response received in step 4 to assist the service that 
triggered this in step Ic (e.g. may provide a location estimate associated with an emergency call to a GMLC). 

Location procedures applicable to E-UTRAN occur in steps 3a and 3b in Figure 5.1-2 and are defined in greater detail 
in this specification. Steps la and 5a are also applicable to E-UTRAN support because of a capability to tunnel 
signalling applicable to steps 3a and 3b. Other steps in Figure 5.1-2 are applicable only to the EPC and are described in 
greater detail and in TS 23.271 [2]. 

Steps 3a and 3b can involve the use of different position methods to obtain location related measurements for a target 
UE and from these compute a location estimate and possibly additional information like velocity. Positioning methods 
supported in this release are summarized in clause 4.3 and described in detail in clause 8. 
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When the eNode B functions as an LCS client, it delivers the Location Service Request to the E-SMLC via the MME, 
as shown in Figure 5.1-2. 

Editor"s Note: The details of this procedure are FFS pending confirmation from SA2. 
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Figure 5.1-2: Location Service Support by E-UTRAN with eNode B as Client 

1. The eNode B requests some location service (e.g. positioning) to the serving MME. 

2. The MME transfers the location service request to an E-SMLC. 

3a. The E-SMLC instigates location procedures with the serving eNode B for the UE - e.g. to obtain positioning 
measurements or assistance data. 

3b. In addition to step 3a or instead of step 3a, the E-SMLC instigates location procedures with the UE - e.g. to 
obtain a location estimate or positioning measurements or to transfer location assistance data to the UE. 

4. The E-SMLC provides a location service response to the MME and includes a location estimate for the UE. 

5. The MME returns a location service response to the eNode B and includes any needed results - e.g. a location 
estimate for the UE. 

It is FFS if handover during an LCS operation with an eNode B as the cUent requires any special handling. 

5.2 E-UTRAN Positioning Operations 

Separately from location service support for particular UEs, an E-SMLC may interact with elements in the E-UTRAN 
in order to obtain measurement information to help assist one or more position methods for all UEs. 

Editor's Note: The details of the related procedures and signalling interactions will need to await RANI completion 
of downlink and possibly uplink position method evaluation and definition. 

5.2.1 Downlink Position IVIethod Support (FFS) 

An E-SMLC can interact with any eNodeB reachable from any of the MMEs with signaling access to the E-SMLC in 
order to obtain location related information to support the downlink position method. Location related information may 
be obtained either once on demand or on a repeated and triggered basis. The information can include timing information 
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for the eNodeB in relation to either absolute GNSS time or timing of other eNodeBs and information about the 
supported cells including PRS schedule. 

Signalling access between the E-SMLC and eNodeB is via any MME with signalling access to both the E-SMLC and 
eNodeB. 

5.3 Functional Description of Elements Related to UE 
Positioning in E-UTRAN 

5.3.1 User Equipment (UE) 

The UE may transmit the needed signals for uplink-based UE Positioning measurements and may make measurements 
of downlink signals from E-UTRAN and other sources such as different GNSS systems. The measurements to be made 
will be determined by the chosen positioning method. 

The UE may also contain LCS applications, or access an LCS application either through communication with a network 
accessed by the UE or through another application residing in the UE. This LCS application may include the needed 
measurement and calculation functions to determine the UE's position with or without network assistance. This is 
outside of the scope of this specification. 

The UE may also, for example, contain an independent positioning function (e.g., GPS) and thus be able to report its 
position, independent of the E-UTRAN transmissions. The UE with an independent positioning function may also make 
use of assistance information obtained from the network. 

5.3.2 eNode B 

The eNode B is a network element of E-UTRAN that may provide measurement results for position estimation and 
makes measurements of radio signals for a target UE and communicates these measurements to an E-SMLC. 

The eNode B may make its measurements in response to requests (e.g., from the E-SMLC), or it may autonomously 
measure and report regularly or when there are significant changes in radio conditions (e.g., changes in the E-UTRAN 
GPS timing of cell frames). 

Editor" s Note: Autonomous measurement and periodic measurement reporting by eNode B is FFS 

5.3.3 Evolved Serving IVIobile Location Centre (E-SIVILC) 

The E-SMLC manages the support of different location services for target UEs, including positioning of UEs and 
delivery of assistance data to UEs. The E-SMLC may interact with the serving eNode B for a target UE in order to 
obtain position measurements for the UE, including uplink measurements made by the eNode B and downlink 
measurements made by the UE that were provided to the eNode B as part of other functions such as for support of 
handover. 

The E-SMLC may interact with a target UE in order to deliver assistance data if requested for a particular location 
service, or to obtain a location estimate if that was requested. 

For positioning of a target UE, the E-SMLC decides on the position methods to be used, based on factors that may 
include the LCS Client type, the required QoS, UE positioning capabilities, and eNode B positioning capabilities. The 
E-SMLC then invokes these positioning methods in the UE and/or serving eNode B. The positioning methods may 
yield a location estimate for UE-based position methods and/or positioning measurements for UE-assisted and network- 
based position methods. The E-SMLC may combine all the received results and determine a single location estimate for 
the target UE (hybrid positioning). Additional information like accuracy of the location estimate and velocity may also 
be determined. 

5.3.4 Location IVIeasurement Unit (LIVIU) 

LMU functionality is not included in this version of the specification. 
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6 Signalling protocols and interfaces 

6.1 Network interfaces supporting positioning operations 

6.1 .1 General LCS control plane architecture 

The general LCS control plane architecture in the EPS applicable to a target UE with E-UTRAN access is defined in 

[2]. 

6.1.2 LTE-Uu interface 

The LTE-Uu interface, connecting the UE to the eNode B over the air, is used as one of several transport links for the 
LTE Positioning Protocol. 

6.1.3 SI -MME interface 

The SI -MME interface between the eNode B and the MME is transparent to all UE-positioning-related procedures. It 
is involved in these procedures only as a transport link for the LTE Positioning Protocol. 

For eNode B related positioning procedures, the SI -MME interface transparently transports both positioning requests 
from the E-SMLC to the eNode B and positioning results from the eNode B to the E-SMLC. 

6.1.4 SLs interface 

The SLs interface, between the E-SMLC and the MME, is transparent to all UE related and eNode B related positioning 
procedures. It is then used only as a transport link for the LTE Positioning Protocols LPP and LPPa. 

The SLs interface supports location sessions instigated by the MME as defined in [2]. LPP and LPPa transport are then 
supported as part of any location session. 

6.2 UE-terminated protocols 
6.2.1 LTE Positioning Protocol (LPP) 

The LTE Positioning Protocol (LPP) is terminated between a target device (the UE in the control-plane case or SET in 
the user-plane case) and a positioning server (the E-SMLC in the control-plane case or SLP in the user -plane case). It 
may use either the control- or user -plane protocols as underlying transport. In this specification, only control plane use 
of LPP is defined. User plane support of LPP is defined in [17] and [18]. 

LPP is a point to point positioning protocol with capabilities similar to those in UMTS RRC ([15]) and GERAN RRLP 
([16]). Whereas RRLP supports positioning of a target MS accessing GERAN and RRC supports positioning of a target 
UE accessing UTRAN, LPP supports positioning and location related services (e.g. transfer of assistance data) for a 
target UE accessing E-UTRAN. To avoid creating new positioning protocols for ftiture access types developed by 
3GPP, and to enable positioning measurements for terrestrial access types other than E-UTRAN, LPP is in principle 
forward-compatible with other access types, even though restricted to E-UTRAN access in this specification. 

LPP further supports the OMA user plane location solution SUPL 2.0, as defined in the OMA SUPL 2.0 standards 
([17], [18]), and is intended to be compatible with the successor protocols of SUPL 2.0 as well. 

LPP messages are carried as transparent PDUs across intermediate network interfaces using the appropriate protocols 
(e.g., Sl-AP over the SI -MME interface, NAS/RRC over the Uu interface). The LPP protocol is intended to enable 
positioning for LTE using a multiplicity of different position methods, while isolating the details of any particular 
positioning method and the specifics of the underlying transport from one another. 

The protocol operates on a transaction basis between a target device and a server, with each transaction taking place as 
an independent procedure. More than one such procedure may be in progress at any given moment. An LPP procedure 
may involve a request/response pairing of messages or one or more 'unsolicited' messages. Each procedure has a single 
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objective (e.g., transfer of assistance data, exchange of LPP related capabilities, or positioning of a target device 
according to some QoS and use of one or more positioning methods). Multiple procedures, in series and/or in parallel, 
can be used to achieve more complex objectives (e.g., positioning of a target device in association with transfer of 
assistance data and exchange of LPP related capabilities). Multiple procedures also enable more than one positioning 
attempt to be ongoing at the same time (e.g., to obtain a coarse location estimate with low delay while a more accurate 
location estimate is being obtained with higher delay). 

An LPP session is defined between a positioning server and the target device, the details of its relation with transactions 
are described in section 4.L2 of [25]. 

A single LPP transaction may be realised as multiple procedures; e.g., a single transaction for provision of assistance 
data might comprise several Provide Assistance Data messages, with each such message constituting a separate 
procedure (since there is no 'multiple unsolicited messages' procedure type). 

For the 3GPP EPS Control Plane solution defined in [2], the UE is the target device and the E-SMLC is the server. For 
SUPL 2.0 support, the SUPL Enabled Terminal (SET) is the target device and the SUPL Location Platform (SLP) is the 
server. The protocol does not preclude the possibility of future developments in control plane and user plane solutions 
(e.g., possible successors of SUPL 2.0, as well as possible future 3GPP control plane solutions). 

All LPP operations and procedures are defined with respect to the target and server, and thus the LPP operations and 
procedures defined here with respect to a UE and an E-SMLC can also be viewed in this more generic context by 
substituting any target for the UE and any server for the E-SMLC. 

LPP further supports multiple positioning methods as defined in section 4.3. 

LPP supports hybrid positioning, in which two or more position methods are used concurrently to provide 
measurements and/or a location estimate or estimates to the server. LPP is forward compatible with the later addition of 
other position methods in later releases (e.g., position methods associated with other types of terrestrial access). 

The operations controlled through LPP are described further in section 7.1. 

6.2.2 Radio Resource Control (RRC) 

The RRC protocol is terminated between the eNode B and the UE. In addition to providing transport for LPP messages 
over the Uu interface, it supports transfer of measurements that may be used for positioning purposes through the 
existing measurement systems specified in [14]. 

6.3 eNB-terminated protocols 

6.3.1 LTE Positioning Protocol Annex (LPPa) 

The LTE Positioning Protocol Annex (LPPa) carries information between the eNode B and the E-SMLC. It is used to 
support the following positioning functions: 

E-CID cases where assistance data or measurements are transferred from the eNode B to the E-SMLC 

data collection from eNodeBs for support of downlink OTDOA positioning 

The LPPa protocol is transparent to the MME. The MME routes the LPPa PDUs transparently based on a short Routing 
ID corresponding to the involved E-SMLC node over S 1 interface without knowledge of the involved LPPa transaction. 
It carries the LPPa PDUs over SI interface either in UE associated mode or non-UE associated mode. 

6.3.2 S1 Application Protocol (S1-AP) 

The Sl-AP protocol, terminated between the MME and the eNode B, is used as transport for LPP and LPPa messages 
over the SI -MME interface. The Sl-AP protocol is also used to instigate and terminate eNode B related positioning 
procedures. 
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6.4 Signalling between an E-SIVILC and UE 
6.4.1 Protocol Layering 

Figure 6.4.1-1 shows the protocol layering used to support transfer of LPP messages between an E-SMLC and UE. The 
abbreviations for all protocols follow those used in [19], with the additions of LPP and LCS-AP (LCS application 
protocol) which denotes a possible new protocol that might be functionally similar to parts of BSSAP-LE (TS 49.031), 
BSSLAP (TS 48.071) and RANAP (TS 25.413). 

Editor's Note: The protocol layering below is copied exactly from [24]. The layers below LPP on the SLs interface 
between the MME and E-SMLC are expected to be defined by CT4. Once this has occurred, the figure 
below can be updated if needed. 



LPP 


; 








LPP 


------ -r ------- 












-^SIAS Rela);^ 






^^^^da^^^ 


RRC 


LCS-AP 


RRC '--i » " 


C) i-Mr 




S1-AP • ^'-' "^ 


Loa-rtr 






PDCP 


PDCP 


SCTP 


SCTP 


SCTP 


SCTP 








RLC 


RLC 


IP 


IP 


IP 


IP 


.------u ------- 








MAC 


MAC 


L2 


L2 


L2 


L2 




L1 


L1 


L1 


L1 


L1 


L1 


LTEUu 




' 


UE 


eNoc 


ieB 


S1-MME 


MME 


SLs 


E-SMLC 



Figure 6.4.1-1 : Protocol Layering for E-SMLC to UE Signalling 

6.4.2 LPP PDU Transfer 

Figure 6.4.2-1 shows the transfer of an LPP PDU between an E-SMLC and UE, in the network- and UE-triggered cases. 
These two cases may occur separately or as parts of a single more complex operation. 
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Figure 6.4.2-1 : LPP PDU transfer between E-SMLC and UE (network- and UE-triggered cases) 

1. Steps 1 to 3 may occur before, after, or at the same time as steps 4 to 7. Steps 1 to 3 and steps 4 to 7 may also be 
repeated. Steps 1 to 3 are triggered when the E-SMLC needs to send an LPP message to the UE as part of some 
LPP positioning activity. The E-SMLC then sends an LCS-AP PDU to the MME carrying an LPP PDU 
comprising the message. 

2. The MME includes a session identifier (a.k.a Routing identifier defined in [26]), which is associated with the 
positioning session between the MME and E-SMLC, and the LPP PDU in the NAS Transport Message and then 
forwards the NAS Transport Message to the serving eNode B in an SI AP Downlink NAS Transport message. 
The MME need not retain state information for this transfer; it can treat any response in step 6 as a separate non- 
associated transfer. 

3. The eNode B forwards the NAS Transport Message to the UE in an RRC DL Information Transfer message. 

4. Steps 4 to 7 are triggered when the UE needs to send an LPP PDU to the E-SMLC as part of some LPP 
positioning activity. If the UE is in ECM-IDLE state, the UE instigates a UE triggered service request as defined 
in [19] in order to establish a signalling connection with the MME and assign a serving eNode B. 

5. The UE includes the session identifier (a.k.a Routing identifier defined in [26]), which has been received in 
step3, and an LPP PDU to the serving eNode B in an RRC UL Information Transfer message. 

6. The eNode B forwards the NAS Transport Message to the MME in an SI AP Uplink NAS Transport message. 

7. The MME forwards the LPP PDU to the E-SMLC in an LCS-AP PDU. 

6.5 Signalling between an E-SMLC an(d eNode B 
6.5.1 Protocol Layering 

Figure 6.5.1-1 shows the protocol layering used to support transfer of LPPa PDUs between an E-SMLC and eNode B. 

The LPPa protocol is transparent to the MME. The MME routes the LPPa PDUs transparently based on a short Routing 
ID which corresponds to the involved E-SMLC node over the S 1 interface without knowledge of the involved LPPa 
transaction. It carries the LPPa PDUs over S 1 interface either in UE associated mode or non-UE associated mode. 
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Figure 6.5.1-1 : Protocol Layering for E-SIVILC to eNode B Signalling 

6.5.2 LPPa PDU Transfer for UE Positioning 

Figure 6.5.2-1 shows LPPa PDU transfer between an E-SMLC and eNode B to support positioning of a particular UE. 
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Figure 6.5.2-1 : LPPa PDU Transfer between an E-SIVILC and eNode B for UE Positioning 

1. Steps 1 to 2 are triggered when the E-SMLC needs to send an LPPa message to the serving eNode B for a target 
UE as part of an LPPa positioning activity. The E-SMLC then sends an LCS-AP PDU to the MME carrying an 
LPPa PDU comprising the message. 

2. The MME forwards the LPPa PDU to the serving eNode B in an S 1 AP Downlink UE Associated LPPa 
Transport message over the S 1 signalling connection corresponding to the UE and includes the Routing ID 
related to the E-SMLC. The MME need not retain state information for this transfer - e.g. can treat any response 
in step 3 as a separate non-associated transfer. 

3. Steps 3 and 4 are triggered when a serving eNode B needs to send an LPPa message to the E-SMLC for a target 
UE as part of an LPPa positioning activity. The eNode B then sends an LPPa PDU to the MME in an SI AP 
Uplink UE Associated LPPa Transport message and includes the Routing ID received in step 2 and the current 
ECGl. 

4. The MME forwards the LPPa PDU to the E-SMLC associated with the Routing ID received in step 3 in an LCS- 
AP PDU and includes the ECGL Steps 1 to 4 may be repeated. 
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6.5.3 LPPa PDU Transfer for Positioning Support 

Figure 6.5.3-1 shows LPPa PDU transfer between an E-SMLC and eNode B when related to gathering data from the 
eNodeB for positioning support for all UEs. 
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Figure 6.5.3-1 : LPPa PDU Transfer between an E-SMLC and eNode B for obtaining eNodeB Data 

1 . Steps 1 and 2 are triggered when the E-SMLC needs to send an LPPa message to an eNode B to obtain data 
related to the eNodeB. The E-SMLC determines an MME with access to the eNodeB and then sends an LCS-AP 
PDU to the MME carrying an LPPa PDU and the identity of the eNodeB. 

2. The MME forwards the LPPa PDU to the identified eNode B in an S 1 AP Downlink Non UE Associated LPPa 
Transport message and includes the Routing ID related to the E-SMLC. The MME need not retain state 
information for this transfer - e.g. can treat any response in step 3 as a separate non-associated transfer. 

3. Steps 3 and 4 are triggered when an eNode B needs to send an LPPa PDU to an E-SMLC containing data 
applicable to the eNB. The eNode B determines an MME with access to the E-SMLC and then sends an LPPa 
PDU to the MME in an SlAP Uplink Non UE Associated LPPa Transport message. The eNodeB includes the 
Routing ID related to the E-SMLC received at step 2. 

4. The MME forwards the LPPa PDU to the E-SMLC associated to the Routing ID indicated in step 3 in an LCS- 
AP PDU. Steps 1 to 4 may be repeated. 



7 General E-UTRAN UE Positioning procedures 

7.1 General LPP procedures for UE Positioning 



7.1.1 



LPP Procedures 



Positioning procedures in the E-UTRAN are modelled as transactions of the LPP protocol using the procedures defined 
in this specification. A procedure consists of a single operation of one of the following types: 

- Exchange of positioning capabilities; 
Transfer of assistance data; 

Transfer of location information (positioning measurements and/or position estimate); 
Error handling; 

- Abort. 

Parallel transactions are permitted (i.e. a new LPP transaction may be initiated, while another one is outstanding). 

As described in section 6.2.1, the protocol operates between a 'target' and a 'server'. In the control-plane context, these 
entities are the UE and E-SMLC respectively; in the SUPL context they are the SET and the SLP. The terms 'target' 
and 'server' are used in the flows in this section to avoid redundancy between the two versions of the positioning 
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operations. A procedure may be initiated by either the target or the server. Both target initiated and server initiated 
procedures are supported. 

7.1.2 Positioning procedures 



7.1.2.1 



Capability transfer 



A UE request for capability from E-SMLC or delivery of the E-SMLC capability to the UE is not supported in this 
version of the specification. 

Capabilities in an LPP context refer to the ability of a target or server to support different position methods defined for 
LPP, different aspects of a particular position method (e.g. different types of assistance data for A-GNSS) and common 
features not specific to only one position method (e.g. ability to handle multiple LPP transactions) . These capabilities 
are defined within the LPP protocol and transferred between the target and the server using LPP transport. 

The exchange of capabilities between a target and a server may be initiated by a request or sent as 'unsolicited' 
information. If a request is used, the server sends an LPP Request Capabilities message to the target device with a 
request for capability information. The target sends an LPP Provide Capabilities message. 



Target 



Server 



-1 . LPP Request Capabilities 



-2. LPP Provide Capabilities 



Figure 7.1.2.1-1 : LPP Capability Transfer procedure 

1 . The server may send a request for the LPP related capabilities of the target. 

2. The target transfers its LPP-related capabilities to the server. The capabilities may refer to particular position 
methods or may be common to multiple position methods. 

LPP Capability Indication procedure is used for unsolicited capability transfer. 



Target 



Server 



1.LPP Provide Capabilities 



7.1.2.2 



Figure 7.1.2.1-2: LPP Capability Indication procedure 



Assistance data transfer 



Assistance data may be transferred either by request or unsolicited. In this version of the specification, assistance data 
delivery is supported only via unicast transport from server to target. 
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-1. LPP Request Assistance Data- 
-2. LPP Provide Assistance Data- 



-3. LPP Provide Assistance Data- 



Figure 7.1.2.2-1 : LPP Assistance Data Transfer procedure 

1. The target may send a request to the server for assistance data and may indicate the particular assistance data 
needed. 

2. The server transfers assistance data to the target. The transferred assistance data should match any assistance 
data requested in step 1 . 

3. Optionally, the server may transfer additional assistance data to the target in one or more additional LPP 
messages. 

LPP Assistance Data Delivery procedure is used for unilateral assistance data transfer. 



Target 



Server 



-1. LPP Provide Assistance Data 



Figure 7.1.2.2-2: LPP Assistance Data Delivery procedure 

This procedure is unidirectional; assistance data are always delivered from the server to the target. 

7.1 .2.3 Location information transfer 

The term 'location information' applies both to an actual position estimate and to values used in computing position 
(e.g., radio measurements or positioning measurements). It is delivered either in response to a request or unsolicited. 
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-1. LPP Request Location Information- 
-2. LPP Provide Location Information- 



-3. LPP Provide Location Information- 



Figure 7.1.2.3-1: LPP Location Information Transfer procedure 

1 . The server may send a request for location information to the target, and may indicate the type of location 
information needed and associated QoS. 

2. In response to step 1, the target transfers location information to the server. The location information transferred 
should match the location information requested in step 1 . 

3. Optionally (e.g., if requested in step 1), the target in step 2 may transfer additional location information to the 
server in one or more additional LPP messages. 

LPP Location Information Delivery procedure is used for unilateral location information transfer. 

NOTE: the LPP Location Information Delivery procedure can only be piggybacked in the MO-LR request. 



Target 



Server 



-1. LPP Provide Location Information 



7.1.2.4 



Figure 7.1.2.3-2: LPP Location Information Delivery procedure 



Multiple transactions 



Multiple LPP transactions may be in progress simultaneously between the same target and server nodes, to improve 
flexibility and efficiency. However, no more than one LPP procedure between a particular pair of target and server 
nodes to obtain location information shall be in progress at any time for the same position method. 

In this example, the objective is to request location measurements from the target, and the server does not provide 
assistance data in advance, leaving the target to request any needed assistance data. A message flow is shown in Figure 
7.L2.4-L 
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-1. LPP Message: Request Location Information [transaction A]- 



-2. LPP IVIessage: Assistance data request [transaction BJ- 



'S. LPP Message: Assistance data delivery [transaction B]- 



-4. LPP Message: Location information [measurements, transaction A]- 



Figure 7.1.2.4-1 : Example of multiple LPP procedures 

1 . The server sends a request to the target for positioning measurements. 

2. The target sends a request for particular assistance data. 

3. The server returns the assistance data requested in step 2. 

4. The target obtains and returns the location information (e.g., positioning method measurements) requested in 
step 1. 

7.1 .2.5 Sequence of Procedures 

LPP procedures are not required to occur in any fixed order, in order to provide greater flexibility in positioning. Thus, 
a UE may request assistance data at any time in order to comply with a previous request for location measurements 
from the E-SMLC; an E-SMLC may instigate more than one request for location information (e.g., measurements or a 
location estimate) in case location results from a previous request were not adequate for the requested QoS; and the 
target device may transfer capability information to the server at any time if not already performed. 

Despite the flexibility allowed by LPP, it is expected that procedures will normally occur in the following order: 

1 . Capability Transfer; 

2. Assistance Data Transfer; 

3. Location Information Transfer (measurements and/or location estimate). 
Specific examples for each positioning method are shown in clause 8. 



7.1.2.6 



Error handling 



The procedure is used to notify the sending endpoint by the receiving endpoint that the receiving LPP message is 
erroneous or unexpected. This procedure is bidirectional at the LPP level; either the target or the server may take the 
role of either endpoint in Figure 7.L2.6-L 
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Target/Server 



-1. LPP Message- 



-2. LPP Message: Error- 



Server/Target 



Figure 7.1.2.6-1: Error handling 

1. The target or server (indicated as 'Target/Server' in Figure 7.1.2.6-1) sends a LPP message to the other endpoint 
(indicated as 'Server/Target'). 

2. If the server or target ('Server/Target') detects that the receiving LPP message is erroneous or unexpected, the 
server or target transfers error indication information to the other endpoint ('Target/Server'). 



7.1.2.7 



Abort 



The procedure is used to notify the other endpoint by one endpoint to abort an ongoing procedure between the two 
endpoints. This procedure is bidirectional at the LPP level; either the target or the server may take the role of either 
endpoint in Figure 7.1.2.7-1. 





1. Ongoing LPP Procedure 



-2. LPP Message: Abort- 



Figure 7.1.2.7-1: Abort 

1 . A LPP procedure is ongoing between target and server. 

2. If the server or target ('Server/Target') determines that the procedure must be aborted, and then the server or 
target sends an LPP Abort message to the other endpoint ('Target/Server') carrying the transaction ID for the 
procedure. 

7.2 General LPPa Procedures for UE Positioning 
7.2.1 LPPa Procedures 

Positioning and data acquisition transactions between an E-SMLC and eNodeB are modelled by using procedures of the 
LPPa protocol. There are two types of LPPa procedures: 

UE associated procedure, i.e. transfer of information for a particular UE (e.g. positioning measurements) 

- Non UE associated procedure, i.e. transfer of information applicable to the eNodeB (e.g. eNB timing 
differences) 

Parallel transactions between the same E-SMLC and eNodeB are supported; i.e. a pair of E-SMLC and eNodeB may 
have more than one instance of an LPPa procedure in execution at the same time. 
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For possible extensibility, the protocol is considered to operate between a generic "access node" (e.g. eNodeB) and a 
"server" (e.g. E-SMLC). A procedure is only initiated by the server. 



Access Node 



Server 



-1. LPPa Procedural Request- 



-2. LPPa Procedural Response- 



-N. LPPa Procedural Response (end transaction)- ■ 



Figure 7.2.1-1 : A single LPPa transaction 

Figure 7.2.1.1-1 shows a single LPPa transaction. The transaction is terminated in step 2 in the case of a non UE 
associated procedure. For a UE associated procedure to gather information concerning the access node, additional 
responses may be allowed (e.g. sending of updated information periodically and/or whenever there is some significant 
change). In this case, the transaction may be ended after some additional responses. In the LPPa protocol, the described 
transaction may be realized by the execution of one procedure defined as a request and a response, followed by a 
procedure defined as a single message to realize the additional responses. 

7.2.2 LPPa transaction types 



7.2.2.1 



Location information transfer 



The term 'location information' applies both to an actual position estimate and to values used in computing position 
(e.g., radio measurements or positioning measurements). It is delivered in response to a request. 



eNode B 



Server 



-1 . LPPa Message: Location information request- 
2. LPPa Message: Location information 



-3. LPPa Message: Location information- 



Figure 7.2.2-1 : Location information transfer 

1 . The server sends a a request for location related information to the eNodeB, and indicates the type of location 
information needed and associated QoS. The request may refer to a particular UE. 

2. In response to step 1, the eNodeB transfers location related information to the server. The location related 
information transferred should match the location related information requested in step 1 . 

3. If requested in step 1, the eNodeB may transfer additional location related information to the server in one or 
more additional LPPa messages when the positioning method is E-CID. 
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7.3 Service Layer Support using combined LPP and LPPa 
Procedures 

As described in [2], UE-positioning -related services can be instigated from the EPC in the case of an NI-LR or MT-LR 
location service, or from the UE in the case of an MO-LR location service. The complete sequence of operations in the 
EPC is defined in [2]. This subclause defines the overall sequences of operations that occur in the E-SMLC, E-UTRAN 
and UE as a result of the EPC operations. 

Some flows in this scenario apply only in particular situations (e.g., only when the UE is in connected mode). The 
lower-layer details of such cases are not shown in the diagrams; for instance, the process of paging a UE to bring it to 
connected mode from idle is not explicitly indicated in these diagrams. 

7.3.1 NI-LR and IVIT-LR Service Support 

Figure 7.3.1-1 shows the sequence of operations for an NI-LR or MT-LR location service, starting at the point where 
the MME initiates the service in the E-SMLC. 



Cue 



eNB 



MM El 



1. Locati( n Request (QoS) 



E-SMLC 



LPP Transactions 



s) 



3. LPPa Tran: !actions(s' 



4. Locatbn Response (Location Estimate) 



Figure 7.3.1-1 : UE Positioning Operations to support an IVIT-LR or NI-LR 

1. The MME sends a location request to the E-SMLC for a target UE and may include associated QoS. 

2. The E-SMLC may obtain location related information from the UE and/or from the serving eNode B. In the 
former case, the E-SMLC instigates one or more LPP procedures to transfer UE positioning capabilities, provide 
assistance data to the UE and/or obtain location information from the UE. The UE may also instigate one or 
more LPP procedures after the first LPP message is received from the E-SMLC (e.g., to request assistance data 
from the E-SMLC). 

3. If the E-SMLC needs location related information for the UE from the eNode B, the E-SMLC instigates one or 
more LPPa procedures. Step 3 is not necessarily serialised with step 2; if the E-SMLC and eNode B have the 
information to determine what procedures need to take place for the location service, step 3 could precede or 
overlap with step 2. 

4. The E-SMLC returns a location response to the MME with any location estimate obtained as a result of steps 2 
and 3. 

7.3.2 IVIO-LR Service Support 

Figure 7.3.2-1 shows the sequence of operations for an MO-LR service, starting at the point where an LCS Client in the 
UE or the user has requested some location service (e.g., retrieval of the UE's location or transfer of the UE's location to 
a third party). 
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Figure 7.3.2-1 : UE Positioning Operations to support an lUIO-LR 

1 . The UE sends a NAS level MO-LR request to the MME. The MO-LR request may carry an LPP PDU to 
instigate one or more LPP procedures to transfer capabilities, request assistance data, request location 
information and/or transfer location information (e.g. location measurements). 

2. The MME sends a location request to the E-SMLC and includes any LPP PDU received in step L 

3. The E-SMLC may obtain location related information from the UE and/or from the serving eNode B. In the 
former case or if an immediate response is needed to any LPP procedure instigated by the UE in step 1 (e.g., a 
request for assistance data), the E-SMLC instigates one or more LPP procedures to transfer UE positioning 
capabilities, provide assistance data to the UE and/or obtain location information from the UE. The UE may also 
instigate further LPP procedures after the first LPP message is received from the E-SMLC (e.g., to request 
assistance data or to request further assistance data). 

4. If the E-SMLC needs location related information for the UE from the eNode B, the E-SMLC instigates one or 
more LPPa procedures. Step 4 may also precede step 3 or occur in parallel with it. 

5. The E-SMLC returns a location response to the MME with any location estimate obtained as a result of steps 3 
and 4, and/or with a final LPP message (e.g., that could provide a location estimate to the UE if requested by the 
UE in step 1). 

6. If the UE requested location transfer to a third party the MME transfers the location received from the E-SMLC 
in step 5 to the third party as defined in [2]. 

7. The MME sends a NAS level MO-LR response to the UE, carrying any final LPP PDU that was received in step 
5. 



8 Positioning methods and Supporting Procedures 

8.1 GNSS positioning methods 
8.1.1 General 

Global Navigation Satellite System (GNSS) is the standard generic term for satellite navigation systems that provide 
autonomous geo-spatial positioning with global or regional coverage. The following GNSSs are supported in this 
version of the specification: 

GPS and its modernization [6,7,8]; 
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- Galileo [9]; 

- GLONASS [10]; 

- Satellite Based Augmentation Systems (SBAS), including WAAS, EGNOS, MSAS, and GAGAN [12]; 

- Quasi-Zenith Satellite System (QZSS) [11]. 

Each global GNSS can be used individually or in combination with others. When used in combination, the effective 
number of navigation satellite signals would be increased: 

extra satellites can improve availability (of satellites at a particular location) and results in an improved ability to 
work in areas where satellite signals can be obscured, such as in urban canyons; 

extra satellites and signals can improve reliability, i.e., with extra measurements the data redundancy is 
increased, which helps identify any measurement outlier problems; 

extra satellites and signals can improve accuracy due to improved measurement geometry and improved ranging 
signals from modernized satellites. 

When GNSS is designed to inter- work with the E-UTRAN, the network assists the UE GNSS receiver to improve the 
performance in several respects. These performance improvements will: 

reduce the UE GNSS start-up and acquisition times; the search window can be limited and the measurements 
speed up significantly; 

increase the UE GNSS sensitivity; positioning assistance messages are obtained via E-UTRAN so the UE GNSS 
receiver can operate also in low SNR situations when it is unable to demodulate GNSS satellite signals; 

allow the UE to consume less handset power than with stand-alone GNSS; this is due to rapid start-up times as 
the GNSS receiver can be in idle mode when it is not needed. 

The network-assisted GNSS methods rely on signalling between UE GNSS receivers (possibly with reduced 
complexity) and a continuously operating GNSS reference receiver network, which has clear sky visibility of the same 
GNSS constellation as the assisted UEs. Two assisted modes are supported: 

UE-Assisted: The UE performs GNSS measurements (pseudo-ranges, pseudo Doppler, etc.) and sends these 
measurements to the E-SMLC where the position calculation takes place, possibly using additional 
measurements from other (non GNSS) sources; 

UE-Based: The UE performs GNSS measurements and calculates its own location, possibly using additional 
measurements from other (non GNSS) sources. 

The assistance data content may vary depending on whether the UE operates in UE-Assisted or UE-Based mode. 

The assistance data signalled to the UE can be broadly classified into: 

data assisting the measurements: e.g. reference time, visible satellite list, satellite signal Doppler, code phase, 
Doppler and code phase search windows; 

data providing means for position calculation: e.g. reference time, reference position, satellite ephemeris, clock 
corrections. 

A UE with GNSS measurement capability may also operate in an autonomous (standalone) mode. In autonomous mode 
the UE determines its position based on signals received from GNSS without assistance from the network. 

8.1 .2 Information to be transferred between E-UTRAN Elements 

This subclause defines the information (e.g., assistance data, measurement data) that may be transferred between E- 
UTRAN elements. 

8.1 .2.1 Information that may be transferred from the E-SMLC to UE 

Table 8.1.2.1-1 lists assistance data for both UE-assisted and UE-based modes that may be sent from the E-SMLC to 
the UE. 
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NOTE: The provision of these assistance data elements and the usage of these elements by the UE depend on the 
E-UTRAN and UE capabilities, respectively. 

Table 8.1.2.1-1 : Information that may be transferred from the E-SMLC to UE 



Assistance Data 



Reference Time 



Reference Location 



Ionospheric IVIodels 



Earth Orientation Parameters 



GNSS-GNSS Time Offsets 



Differential GNSS Corrections 



Ephemeris and Clock Models 



Real-Time Integrity 



Data Bit Assistance 



Acquisition Assistance 



Almanac 



UTC Models 



8.1.2.1.1 



Reference Time 



Reference Time assistance provides the GNSS receiver with coarse or fine GNSS time information. The specific GNSS 
system times (e.g., GPS, Galileo, Glonass system time) shall be indicated with a GNSS ID. 

In case of coarse time assistance only, the Reference Time provides an estimate of the current GNSS system time 
(where the specific GNSS is indicated by a GNSS ID). The E-SMLC should achieve an accuracy of H-/- 3 seconds for 
this time including allowing for the transmission delay between E-SMLC and UE. 

In case of fine time assistance, the Reference Time provides the relation between GNSS system time (where the specific 
GNSS is indicated by a GNSS ID) and E-UTRAN air-interface timing. 



8.1.2.1.2 



Reference Location 



Reference Location assistance provides the GNSS receiver with an apriori estimate of its location (e.g., obtained via 
Cell-ID, downlink positioning, etc.) together with its uncertainty. 

The geodetic reference frame shall be WGS-84, as specified in [4]. 



8.1.2.1.3 



Ionospheric Models 



Ionospheric Model assistance provides the GNSS receiver with parameters to model the propagation delay of the GNSS 
signals through the ionosphere. Ionospheric Model parameters as specified by GPS [6], Galileo [9], and QZSS [11] may 
be provided. 



8.1.2.1.4 



Earth Orientation Parameters 



Earth Orientation Parameters (EOP) assistance provides the GNSS receiver with parameters needed to construct the 
ECEF-to-ECI coordinate transformation as specified by GPS [6] . 



8.1.2.1.5 



GNSS-GNSS Time Offsets 



GNSS-GNSS Time Offsets assistance provides the GNSS receiver with parameters to correlate GNSS time (where the 
specific GNSS is indicated by a GNSS-1 ID) of one GNSS with other GNSS time (where the specific GNSS is 
indicated by a GNSS-2 ID). GNSS-GNSS Time Offsets parameters as specified by GPS [6], GaUleo [9], Glonass [10], 
and QZSS [11] may be provided. 



8.1.2.1.6 



Differential GNSS Corrections 



Differential GNSS Corrections assistance provides the GNSS receiver with pseudo-range and pseudo-range -rate 
corrections to reduce biases in GNSS receiver measurements as specified in [13]. The specific GNSS for which the 
corrections are valid is indicated by a GNSS-ID. 
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8.1.2.1.7 



Ephemeris and Clock Models 



Ephemeris and Clock Models assistance provides the GNSS receiver with parameters to calculate the GNSS satellite 
position and clock offsets. The various GNSSs use different model parameters and formats, and all parameter formats as 
defined by the individual GNSSs are supported by the signalling. 



8.1.2.1.8 



Real-Time Integrity 



Real-Time Integrity assistance provides the GNSS receiver with information about the health status of a GNSS 
constellation (where the specific GNSS is indicated by a GNSS ID). 



8.1.2.1.9 



Data Bit Assistance 



Data Bit Assistance provides the GNSS receiver with information about data bits or symbols transmitted by a GNSS 
satellite at a certain time (where the specific GNSS is indicated by a GNSS ID). This information may be used by the 
UE for sensitivity assistance (data wipe-off) and time recovery. 



8.1.2.1.10 



Acquisition Assistance 



Acquisition Assistance provides the GNSS receiver with information about visible satellites, reference time, expected 
code-phase, expected Doppler, search windows (i.e., code and Doppler uncertainty) and other information of the GNSS 
signals (where the specific GNSS is indicated by a GNSS ID) to enable a fast acquisition of the GNSS signals. 



8.1.2.1.11 



Almanac 



Almanac assistance provides the GNSS receiver with parameters to calculate the coarse (long-term) GNSS satellite 
position and clock offsets. The various GNSSs use different model parameters and formats, and all parameter formats as 
defined by the individual GNSSs are supported by the signalling. 



8.1.2.1.12 



UTC Models 



UTC Models assistance provides the GNSS receiver with parameters needed to relate GNSS system time (where the 
specific GNSS is indicated by a GNSS ID) to Universal Coordinated Time. The various GNSSs use different model 
parameters and formats, and all parameter formats as defined by the individual GNSSs are supported by the signalling. 

8.1 .2.2 Information that may be transferred from the UE to E-SMLC 

The information that may be signalled from UE to the E-SMLC is listed in table 8.1.2.2-1. 

Table 8.1.2.2-1-2: Information that may be transferred from UE to the E-SMLC 



Information 


UE-assisted 


UE-based/ 
standalone 


Latitude/Longitude/Altitude, together with uncertainty shape 


No 


Yes 


Velocity, together with uncertainty shape 


No 


Yes 


Reference Time, possibly together with GNSS-E-UTRAN 
time association and uncertainty 


Yes 


Yes 


Indication of used positioning methods in the fix 


No 


Yes 


Code phase measurements 


Yes 


No 


Doppler measurements 


Yes 


No 


Carrier phase measurements 


Yes 


No 


Measurement quality parameters for each measurement 


Yes 


No 


Additional, non-GNSS related measurement information 


Yes 


No 



8.1.2.2.1 



GNSS Measurement Information 



The GNSS measurement information reported from the UE to the E-SMLC depends on the GNSS mode (i.e., UE-based, 
autonomous (standalone), or UE-assisted). 
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8.1.2.2.1.1 UE-based mode 

In UE-based or standalone mode, the GNSS receiver reports the latitude, longitude and possibly altitude, together with 
an estimate of the location uncertainty, if available. 

If requested by the E-SMLC and supported by the UE, the GNSS receiver may report its velocity, possibly together 
with an estimate of the uncertainty, if available. 

If requested by the E-SMLC and supported by the UE, the GNSS receiver may report the relation between GNSS 
system time (where the specific GNSS is indicated by a GNSS ID; the specific GNSS system time may be selected by 
the UE) and E-UTRAN air-interface timing. This information may be used by the E-SMLC to assist other UEs in the 
network. 

The UE should also report an indication of which GNSSs and possibly other location methods have been used to 
calculate a fix. 

8.1.2.2.1.2 UE-assisted mode 

In UE-assisted mode, the GNSS receiver reports the Code Phase and Doppler measurements together with associated 
quality estimates. These measurements enable the E-SMLC to calculate the location of the UE, possibly using other 
measurements and data. 

If requested by the E-SMLC and supported by the UE, the GNSS receiver may report Carrier Phase measurements 
together with associated quality measurements, if available. 

If requested by the E-SMLC and supported by the UE, the GNSS receiver may report the relation between GNSS 
system time (where the specific GNSS is indicated by a GNSS ID; the specific GNSS system time may be selected by 
the UE) and E-UTRAN air-interface timing. This information may be used by the E-SMLC to assist other UEs in the 
network. 

8.1 .2.2.2 Additional Non-GNSS Related Information 

Additional non-GNSS measurements performed by E-UTRAN or UE may be used by the E-SMLC or UE to calculate 
or verify a location estimate. This information may include downlink positioning measurements, pathloss and signal 
strength related measurements, etc. 

8.1.3 Assisted-GNSS Positioning Procedures 
8.1 .3.1 Capability Transfer Procedure 

The Capability Transfer procedure for Assisted-GNSS positioning is described in subclause 7.1.2.1. 

8.1.3.1.1 Void 



8.1 .3.2 Assistance Data Transfer Procedure 

The purpose of this procedure is to enable the E-SMLC to provide assistance data to the UE (e.g., as part of a 
positioning procedure) and the UE to request assistance data from the E-SMLC (e.g., as part of a positioning procedure 
or for autonomous self location (i.e., UE determines its own location)). 

8.1 .3.2.1 E-SMLC initiated Assistance Data Delivery 

Figure 8.1.3.2.1-1 shows the Assistance Data Delivery operations for the network-assisted GNSS method when the 
procedure is initiated by the E-SMLC. 
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UE 



E-SMLC 



1. LPP Provide Assistance Data 



Figure 8.1.3,2,1-1: E-SMLC-initiated Assistance Data Delivery Procedure 

(1) The E-SMLC determines that assistance data needs to be provided to the UE (e.g., as part of a positioning 

procedure) and sends an LPP Provide Assistance Data message to the UE. This message may include any of the 
GNSS assistance data defined in subclause 8.1.2.1. 



8.1.3.2.2 



UE initiated Assistance Data Transfer 



Figure 8.1.3.2.2-1 shows the Assistance Data Transfer operations for the network-assisted GNSS method when the 
procedure is initiated by the UE. 
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E-SMLC 
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2. LPP Provide Assistance Data 



Figure 8.1.3.2.2-1 : UE-initiated Assistance Data Transfer Procedure 

(1) The UE determines that certain A-GNSS assistance data are desired (e.g., in case the UE requires its own 
location with autonomous self location or as part of a positioning procedure when the E-SMLC provided 
assistance data are not sufficient for the UE to fulfill the request) and sends a LPP Request Assistance Data 
message to the E-SMLC. This request includes an indication of which specific A-GNSS assistance data are 
requested for each GNSS, possibly together with additional information (e.g., for which GNSS signal types, or 
satellites, or times the assistance is requested, etc.). Additional information concerning the UE's approximate 
location and serving and neighbour cells may also be provided in the Request Assistance Data message and/or in 
an accompanying Provide Location Information message to help the E-SMLC provide appropriate assistance 
data. This additional data may include the UE's last known location if available, the cell IDs of the UE serving 
eNodeB and possibly neighbour eNodeBs, as well as E-CID measurements. 

(2) The E-SMLC provides the requested assistance data in a LPP Provide Assistance Data message, if available at 
the E-SMLC. The entire set of assistance data may be delivered in one or several LPP messages, e.g., one 
message per GNSS. In this case, this step may be repeated by the E-SMLC several times. If any of the UE 
requested assistance data in step (1) are not provided in step 2, the UE shall assume that the requested assistance 
data are not supported, or currently not available at the E-SMLC. If none of the UE requested assistance data in 
step (1) can be provided by the E-SMLC, return any information that can be provided in an LPP message of type 
Provide Assistance Data which includes a cause indication for the not provided assistance data. 
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8.1.3.3 



Location Information Transfer Procedure 



The purpose of this procedure is to enable the E-SMLC to request position measurements or location estimate from the 
UE, or to enable the UE to provide location measurements to the E-SMLC for position calculation (e.g., in case of basic 
self location where the UE requests its own location). 



8.1.3.3.1 



E-SMLC initiated Location Information Transfer Procedure 



Figure 8.1.3.3.1-1 shows the Location Information Transfer operations for the network-assisted GNSS method when the 
procedure is initiated by the E-SMLC. 



UE 



E-SMLC 



-1. LPP Request Location Information 



-2. LPP Provide Location Information 



Figure 8.1.3.3.1-1 : E-SMLC-initiated Location Information Transfer Procedure 

(l)The E-SMLC sends a LPP Request Location Information message to the UE for invocation of A-GNSS 

positioning. This request includes positioning instructions such as the GNSS mode (UE-assisted, UE-based, UE- 
based preferred but UE-assisted allowed, UE-assisted preferred, but UE-based allowed, standalone), positioning 
methods (GPS, Galileo, Glonass, etc. and possibly non-GNSS methods, such as downlink positioning or E-CID), 
specific UE measurements requested if any, such as fine time assistance measurements, velocity, carrier phase, 
multi-frequency measurements, and quality of service parameters (accuracy, response time). 

(2) The UE performs the requested measurements and possibly calculates its own location. The UE sends an LPP 
Provide Location Information message to the E-SMLC before the Response Time provided in step (1) elapsed. If 
the UE is unable to perform the requested measurements, or if the Response Time provided in step 1 elapsed 
before any of the requested measurements have been obtained, the UE returns any information that can be 
provided in an LPP message of type Provide Location Information which includes a cause indication for the not 
provided location information. 



8.1.3.3.2 



UE-initiated Location Information Delivery Procedure 



Figure 8.1.3.3.2-1 shows the Location Information delivery operations for the UE-assisted GNSS method when the 
procedure is initiated by the UE. 



UE 



E-SMLC 



1 . LPP Provide Location Information 



Figure 8.1.3.3.2-1: UE-initiated Location Information Delivery Procedure 
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(1) The UE sends an LPP Provide Location Information message to the E-SMLC. The Provide Location Information 
message may include any UE measurements (GNSS pseudo-ranges, and other measurements) already available 
at the UE. 

8.2 Downlink positioning method 

8.2.1 General 

In the downlink positioning method, the UE positioning is estimated based on measurements taken at the UE of 
downlink radio signals from multiple eNodeBs, along with knowledge of the geographical coordinates of the measured 
eNodeBs and their relative downlink timing. 

The specific positioning techniques used to estimate the UE"s location from this information are beyond the scope of 
this specification. 

8.2.2 Transferred information 

This subclause defines the information that may be transferred between E-SMLC and UE/eNodeB. 

8.2.2.1 Assistance Data that may be transferred from the E-SMLC to UE 

The following assistance data may be transferred from the E-SMLC to the UE: 

Physical cell IDs (PCIs) and global cell IDs (GCIs) of candidate cells for measurement; 
Timing relative to the serving eNodeB of candidate cells; 

8.2.2.2 Assistance Data that may be transferred from the eNodeB to E-SMLC 

The following assistance data may be transferred from the eNodeB to the E-SMLC: 

- PCI and GCI of the cells under the eNodeB; 

Timing information on the eNodeB; 

Geographical candidates of the eNodeB. 

An eNodeB may provide assistance data relating only to itself via LPPa signalling, although assistance data from 
several eNodeBs may be acquired through other mechanisms, see NOTE below. 

NOTE: The assistance data described in this section are not necessarily transferred only from the eNodeB, and in 
some deployment options may not be delivered from the eNodeB at all; they may also be delivered to the 
E-SMLC through OA&M or other mechanisms external to the E-UTRAN. In addition, in cases where 
assistance data are delivered from the eNodeB, how the eNodeB acquires the data is outside the scope of 
this specification. 



8.2.2.3 



Location Information that may be transferred from the UE to E-SMLC 



The information that may be signalled from UE to the E-SMLC is listed in Table 8.2.2.3-1. The individual UE 
measurements are defined in [20, 21]. 

Table 8.2.2.3-1 : Information that may be transferred from UE to the E-SMLC 



Information 


Measurements 


Downlink Measurement Results List for 
EUTRA 


Physical cell IDs 


Global cell IDs 


Downlink timing measurements 



Editor's Note: The details of the measurements are FFS. 
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8.2.3 Downlink Positioning Procedures 



The procedures described in this subclause support downhnk positioning measurements obtained by the UE and 
provided to the E-SMLC using LPP, or obtained by the eNode B and provided to the E-SMLC using LPPa. 

In this version of the specification only the UE-assisted downlink positioning is supported. 

8.2.3.1 Capability Transfer Procedure 

The Capability Transfer procedure for Downlink positioning is described in subclause 7.1.2.1. 

8.2.3.1.1 Void 

8.2.3.2 Assistance Data Transfer Procedure 

8.2.3.2.1 Assistance Data Transfer between E-SMLC and UE 

The purpose of this procedure is to enable the E-SMLC to provide assistance data to the UE (e.g., as part of a 
positioning procedure) and the UE to request assistance data from the E-SMLC (e.g., as part of a positioning procedure 
or for autonomous self location (i.e., UE determines its own location)). 

8.2.3.2.1 .1 E-SMLC-initiated assistance data delivery 

Figure 8.2.3.2.1.1-1 shows the Assistance Data Delivery operations for the downlink positioning method when the 
procedure is initiated by the E-SMLC. 



UE 



E-SMLC 



1. LPP Provide Assistance Data 



Figure 8.2.3.2.1.1-1 : E-SMLC-initiated Assistance Data Delivery Procedure 



(l)The E-SMLC determines that assistance data needs to be provided to the UE (e.g., as part of a positioning 
procedure) and sends an LPP Provide Assistance Data message to the UE. This message may include any of the 
downlink positioning assistance data defined in subclause 8.2.2.1. 

8.2.3.2.1 .2 UE-initiated assistance data transfer 

Figure 8.2.3.2.1.2-1 shows the Assistance Data Transfer operations for the downlink positioning method when the 
procedure is initiated by the UE. 
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UE 



E-SMLC 



-1. LPP Request Assistance Data 



-2. LPP Provide Assistance Data 



Figure 8.2.3.2.1.2-1: UE-initiated Assistance Data Transfer Procedure 

(l)The UE determines that certain downlink positioning assistance data are desired (e.g., in case the UE requires its 
own location with autonomous self location, or as part of a positioning procedure when the E-SMLC -provided 
assistance data are not sufficient for the UE to fulfill the request) and sends an LPP Request Assistance Data 
message to the E-SMLC. This request includes an indication of which specific downlink assistance data are 
requested. Additional information concerning the UE's approximate location and serving and neighbour cells 
may also be provided in the Request Assistance Data message and/or in an accompanying Provide Location 
Information message to help the E-SMLC provide appropriate assistance data. This additional data may include 
the UE's last known location if available, the cell IDs of the UE serving eNodeB and possibly neighbour 
eNodeBs, as well as E-CID measurements. 

(2) The E-SMLC provides the requested assistance in an LPP Provide Assistance Data message, if available at the 
E-SMLC. If any of the UE requested assistance data in step (1) are not provided in step 2, the UE shall assume 
that the requested assistance data are not supported, or currently not available at the E-SMLC. If none of the UE 
requested assistance data in step (1) can be provided by the E-SMLC, return any information that can be 
provided in an LPP message of type Provide Assistance Data which includes a cause indication for the not 
provided assistance data. 



8.2.3.2.2 



Assistance Data Delivery between E-SMLC and eNodeB 



The purpose of this procedure is to enable the eNodeB to provide assistance data to the E-SMLC, for subsequent 
delivery to the UE using the procedures of sub clause 8.2.3.2.1 or for use in the calculation of positioning estimates at 
the E-SMLC. 



8.2.3.2.2.1 



Void 



8.2.3.2.2.2 



E-SMLC-initiated assistance data delivery to the E-SMLC 



Figure 8.2.3.2.2.2-1 shows the Assistance Data Delivery operation from the eNodeB to the E-SMLC for the downlink 
positioning method, in the case that the procedure is initiated by the E-SMLC. 



eNode B 




E-SMLC 


(1) 


^ 


LPPa MessageCType: OTDOA INFORMATION 
REQUEST) 






(2) 


LPPa Message(Type: OTDOA INFORMATION RESPONSE/ 

FAILURE) ^ 










^ 





Figure 8.2.3.2.2.2-1 : E-SIVILC-initiated Assistance Data Delivery Procedure 

(1) The E-SMLC determines that certain downlink positioning assistance data are desired (e.g., as part of a periodic 
update or as triggered by QAM) and sends an LPPa OTDOA INFORMATION REQUEST message to the 
eNode B. This request includes an indication of which specific downlink assistance data are requested. 
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(2) The eNode B provides the requested assistance in an LPPa OTDOA INFORMATION RESPONSE message, if 
available at the eNode B. If the eNode B is not able to provide any information, it returns an OTDOA 
INFORMATION FAILURE message indicating the cause of the failure. 



8.2.3.3 



Location Information Transfer Procedure 



The purpose of this procedure is to enable the E-SMLC to request position measurements from the UE, or to enable the 
UE to provide location measurements to the E-SMLC for position calculation (e.g., in case of basic self location where 
the UE requests its own location). 



8.2.3.3.1 



E-SMLC-initiated Location Information Transfer 



Figure 8.2.3.3.1-1 shows the Location Information Transfer operations for the downlink positioning method when the 
procedure is initiated by the E-SMLC. 



UE 



E-SMLC 



-1. LPP Request Location Information 



-2. LPP Provide Location Information 



Figure 8.2.3.3.1-1: E-SMLC-initiated Location Information Transfer Procedure 

(1) The E-SMLC sends an LPP Request Location Information message to the UE. This request includes indication 
of downlink measurements requested, including any needed measurement configuration information, and 
required response time. 

(2) The UE obtains downlink measurements as requested in step 1. The UE then sends an LPP Provide Location 
Information message to the E-SMLC, before the Response Time provided in step (1) elapsed, and includes the 
obtained downlink measurements. If the UE is unable to perform the requested measurements, or the Response 
Time elapsed before any of the requested measurements were obtained, the UE returns any information that can 
be provided in an LPP message of type Provide Location Information which includes a cause indication for the 
not provided location information. 



8.2.3.3.2 



UE-initiated Location Information Delivery procedure 



Figure 8.2.3.3.2-1 shows the Location Information Delivery procedure operations for the downlink positioning method 
when the procedure is initiated by the UE. 



UE 



E-SMLC 



1 . LPP Provide Location Information 



Figure 8.2.3.3.2-1: UE-initiated Location Information Delivery Procedure. 

(I) The UE sends an LPP Provide Location Information message to the E-SMLC. The Provide Location Information 
message may include any UE downlink measurements already available at the UE. 
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8.3 Enhanced cell ID positioning methods 

8.3.1 General 

In the Cell ID (CID)-based method, the UE position is estimated with the knowledge of the geographical coordinates of 
its serving eNodeB. Enhanced Cell ID (E-CID) positioning refers to techniques which use additional UE and/or 
E-UTRAN radio resource related measurements to improve the UE location estimate. For E-UTRAN access, these 
measurements may include [20, 21]: 

UE measurements ([20], [21]): 

Reference signal received power (RSRP); 

Reference Signal Received Quality (RSRQ); 

UE Rx - Tx time difference. 

E-UTRAN measurements ([20], [21]): 

eNB Rx - Tx time difference 

Timing Advance (Tadv): 

Typel: T^dv = (eNB Rx - Tx time difference) + (UE Rx - Tx time difference) 

Type2: Tadv = eNB Rx - Tx time difference; 

- Angle of Arrival (AoA). 

Various techniques exist to use these measurements to estimate the location of the UE. The specific techniques are 
beyond the scope of this specification. 

8.3.2 Information to be transferred between E-UTRAN Elements 

This sub clause defines the information (e.g., measurement data) that may be transferred between E-UTRAN elements. 

8.3.2.1 Information that may be transferred from the E-SMLC to UE 

UE-assisted Enhanced Cell-ID location does not require any assistance data to be transferred from the E-SMLC to the 
UE. 

UE-Based Enhanced Cell-ID location is not supported in this version of the specification. 

8.3.2.2 Information that may be transferred from the UE to E-SMLC 

The information that may be signalled from UE to the E-SMLC is listed in table 8.3.2.2-1. 

Table 8.3.2.2-1 : Information that may be transferred from UE to the E-SMLC 



Information 


UE-assisted 


Evolved Cell Global Identifier (ECGI)/Physical Cell ID 


Yes 


Reference signal received power (RSRP) 


Yes 


Reference Signal Received Quality (RSRQ) 


Yes 


UE Rx - Tx time difference 


Yes 



8.3.2.3 Information that may be transferred from the eNodeB to E-SMLC 

The information that may be signalled from eNodeB to the E-SMLC is listed in table 8.3.2.3-1. 
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Table 8.3.2.3-1 : Information that may be transferred from eNB to the E-SMLC 



Information 



Timing Advance (Tadv) 



Angle of Arrival (AoA) 



E-UTRA Measurement Results List: 



Evolved Cell Global Identifier (ECGI)/Physical Cell ID 



Reference signal received power (RSRP) 



Reference Signal Received Quality (RSRQ) 



8.3.3 Downlink E-CID Positioning Procedures 

The procedures described in this subclause support E-CID related measurements obtained by the UE and provided to 
the E-SMLC using LPP. The term 'downlink' is intended to indicate that from the E-SMLC perspective the involved 
measurements are provided by the UE; this set of procedures might also be considered as 'UE-assisted, E-SMLC -based 
E-CID'. 

8.3.3.1 Capability Transfer Procedure 

The Capability Transfer procedure for E-CID positioning is described in subclause 7.L2.L 

8.3.3.1.1 Void 

8.3.3.2 Assistance Data Delivery Procedure 

Assistance data delivery is not required for UE- or eNB-assisted forms of E-CID positioning. 



8.3.3.3 



Location Information Transfer Procedure 



The purpose of this procedure is to enable the E-SMLC to request position measurements from the UE, or to enable the 
UE to provide location measurements to the E-SMLC for position calculation (e.g., in case of basic self location where 
the UE requests its own location). 



8.3.3.3.1 



E-SMLC-initiated Location Information Transfer 



Figure 8.3.3.3-1 shows the Location Information Transfer operations for the E-CID method when the procedure is 
initiated by the E-SMLC. 



UE 



E-SMLC 



-1. LPP Request Location Information 



-2. LPP Provide Location Information 



Figure 8.3.3.3-1: E-SMLC-initiated Location Information Transfer Procedure. 

(1) The E-SMLC sends a LPP Request Location Information message to the UE for invocation of E-CID 

positioning. This request includes the E-CID measurements requested by the E-SMLC and supported by the UE 
as listed in Table 8.3.2.2-1 together with a required response time. 
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(2) The UE performs the requested measurements and sends an LPP Provide Location Information message to the 
E-SMLC before the Response Time provided in step (1) elapsed. If the UE is unable to perform the requested 
measurements, or if the Response Time provided in step 1 elapsed before any of the requested measurements 
have been obtained, the UE returns any information that can be provided in an LPP message of type Provide 
Location Information which includes a cause indication for the not provided location information. 



8.3.3.3.2 



UE-initiated Location Information Delivery procedure 



Figure 8.3.3.3.2-1 shows the Location Information Delivery procedure operations for the E-CID method when the 
procedure is initiated by the UE. 



UE 



E-SMLC 



1 . LPP Provide Location Information 



Figure 8.3.3.3.2-1: UE-initiated Location Information Delivery Procedure. 

(1) The UE sends an LPP Provide Location Information message to the E-SMLC. The Provide Location Information 
message may include any UE measurements already available at the UE. 

8.3.4 Uplink E-CID Positioning Procedures 

The procedures described in this sub clause support E-CID related measurements obtained by the eNodeB and provided 
to the E-SMLC using LPPa. The term "uplink" is intended to indicate that from the E-SMLC point of view, the 
involved measurements are provided by the eNodeB; this set of procedures might also be considered as 'eNB-assisted 
E-CID'. An example of this uplink E-CID positioning method is AoAh-Tadv- 

NOTE: Uplink E-CID positioning does not require LCS support in the UE and therefore, works also with legacy 
UEs (assuming that any involved measurements delivered in RRC are supported by the legacy UEs). 

8.3.4.1 Position Capability Transfer Procedure 

The position capability transfer procedure is not applicable to uplink E-CID positioning. 

8.3.4.2 Assistance Data Delivery Procedure 

The assistance data delivery procedure is not applicable to uplink E-CID positioning. 

8.3.4.3 Position Measurement Procedure 

The purpose of this procedure is to enable the E-SMLC to request position measurements from the eNodeB. 

8.3.4.3.1 E-SMLC-initiated Position Measurement 

Figure 8.3.4.3. 1-1 shows the Position Measurement operations for the uplink E-CID method when the procedure is 
initiated by the E-SMLC. 
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Figure 8.3.4.3.1-1: E-SMLC-initiated Position IVIeasurement Procedure 

(1) The E-SMLC sends an LPPa E-CID MEASUREMENT INITIATION REQUEST message to the eNodeB. This 
request includes indication of E-CID measurements requested and whether the result is expected only once or 
periodically. 

(2) If the E-SMLC in step (1) requested UE measurements (i.e., RSRP, RSRQ measurements), or if the eNodeB 
requires UE measurements associated with the measurements requested by the E-SMLC (e.g., Tadv type 1, 
which requires a UE Tx-Rx time difference measurement to be delivered from the UE to the eNodeB), the 
eNodeB may configure the UE to report the measurement information requested as specified in [14]. 

(3) If the result is expected only once and the eNodeB obtains E-CID measurements as requested, the eNodeB sends 
an LPPa E-CID MEASUREMENT INITIATION RESPONSE to the E-SMLC, which includes the obtained E- 
CID measurements. If the result is expected periodically and the eNodeB is able to configure the E-CID 
measurements as requested, the eNodeB sends an LPPa E-CID MEASUREMENT INITIATION RESPONSE to 
the E-SMLC, which does not include any result. The eNodeB reports then the requested measurements by 
initiating the E-CID Measurement Report procedure, with the requested periodicity. If the eNodeB is unable to 
initiate the requested measurements as configured by the request from the E-SMLC, or is unable to instigate 
required RRC procedures to obtain the requested measurements from the UE, the eNodeB sends an LPPa E-CID 
MEASUREMENT INITIATION FAILURE message providing the error reason. If the failure occurs during a 
periodic reporting, the eNodeB sends an LPPa E-CID MEASUREMENT FAILURE INDICATION message. 

8.4 Downlink Supporting Procedures 

8.4.1 General 

An E-SMLC is enabled to request downlink location related information from the E-UTRAN in order to support 
downlink positioning. LPPa is employed for this between the E-SMLC and each eNodeB reachable from the E-SMLC 
via any of the MMEs with signalling access to the E-SMLC. 

8.4.2 Location Related Information 

The information that may be transferred from an eNodeB to the E-SMLC to support downlink positioning is listed in 
table 8.4.2-1. 

Table 8.4.2-1 : Information that may be transferred from an eNodeB to the E-SMLC for the Downlink 

Position Method Support 



Information 


UE-assisted 


Global cell IDs (ECGIs) of eNodeB 


Yes 


Physical cell IDs (PGIs) of eNodeB 


Yes 


PRS Scheduling 


Yes 


If synchronized: SFN initialization time of eNB relative to 
time reference 


Yes 
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8.4.3 Location Related Information Acquisition Procedure 

The purpose of this procedure is to enable an E-SMLC to request downlink location related information from an 
eNodeB. 



8.4.3.1 



On Demand Procedure 



Figure 8.4.3. 1-1 shows the location information acquisition operation for the downlink positioning method when 
information is needed on demand in real time. 



eNB 



E-SMLC 



-1 . LPPa Message (Type: Request Location Information)- 
-2. LPPa Message (Type: Provide Location Information)- 



Figure 8.4.3.1-1 : E-SMLC-initiated On Demand Procedure for Location Information Applicable to 

Downlink 

(1) The E-SMLC sends an LPPa message of type Request Location Information to the eNodeB. This request 
includes an indication of the downlink related information requested. 

(2) The eNodeB obtains the information requested in step 1 using previously configured or stored information 
and/or real time measurements in the case of a request for timing information where recent timing information is 
not already available. The eNodeB then sends an LPPa message of type Provide Location Information to the E- 
SMLC. If the eNodeB is unable to obtain any of the requested information, the eNodeB sends an LPPa failure 
message, providing the error reason. 



8.4.3.2 



Triggered Procedure 



Figure 8.4.3.2-1 shows the location information acquisition operation for the downlink positioning method when 
information is needed on a triggered basis. 



eNB 



E-SMLC 



-1 . LPPa Message (Type: Request Location Information)- 
-2. LPPa Message (Type: Provide Location Information)— 



-3. LPPa Message (Type: Provide Location Infornnation)- 



Figure 8.4.3.2-1 : E-SMLC-initiated Triggered Procedure for Location Information Applicable to 

Downlink 

(1) The E-SMLC sends an LPPa message of type Request Location Information to the eNodeB. This request 
includes an indication of the downlink related information requested, triggering criteria for responses (e.g. 
periodic time interval). 

(2) In response to step 1, the eNodeB obtains the information requested using already available information and/or 
real time measurements. The eNodeB then sends an LPPa message of type Provide Location Information to the 
E-SMLC carrying this information. If the eNodeB is unable to obtain the requested information partly or 
completely, the eNodeB sends an LPPa failure message. 
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(3) When the trigger criteria provided in step 1 indicate the need for a new report the eNodeB obtains the latest 
information. The eNodeB then sends a further LPPa message of type Provide Location Information to the E- 
SMLC containing this information If the eNodeB is unable to obtain the requested information, partly or 
completely, the eNodeB sends an LPPa failure message. 
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Annex A (informative): 
Definitions and Terms 



[FFS; intended for definitions and terminology more extensive than the acronym definitions.] 
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Annex B (informative): Use of LPP with SUPL 

The design goal of LPP is to enable it to be used in user plane location solutions such as OMA SUPL ([17], [18]) and 
this informative annex shows how LPP can be used in SUPL 2.0. 



B.1 SUPL 2.0 Positioning IVIethods and Positioning 
Protocols 

The following table shows how the 3GPP positioning protocols are supported in SUPL 2.0. 

Table B.1-1 : SUPL support of positioning methods 



Positioning Protocol: 


RRLP 

(GSM/GPRS/WCDMA/ 

LTE/WLAN/WiMAX) 


RRC 
(WCDMA) 


LPP 
(LTE) 


Positioning Method: 


A-GPS (A-GANSS) SET Assisted 


■/ 


^ 


^ 


A-GPS (A-GANSS) SET Based 


• 


^ 


• 


Autonomous GPS/GANSS 


•/ 


•/ 


•/ 


Enhanced Cell ID 


V 


■/ 


/ 


Enhanced Observed Time Difference 
(E-OTD) 


•y (GSM only) 


NA 


NA 


Observed Time Difference of Arrival 
(OTDOA) 


NA 


^ 


^ 



Note: What is referred to in the SUPL specifications as 'Enhanced Cell ID is a UE- Assisted positioning mode 
where the neighbouring cell measurements are carried at the SUPL layer (in the SUPL_POS_INIT for 
example). For LTE, the ASN.l container for this mode is defined as follows: 



LteCelllnformation : 


:= SEQUENCE { 












refMCC 


INTEGER (0. 


.999) , -- Mobile 


Country Code 










refMNC 


INTEGER (0 . 


.999) , -- Mobile 


Network Code 










refCI 


BIT STRING(SIZE (29)), -- ] 


[jTE Cell-Id including the 


CSG 


bit 




tA 


INTEGER (0. 


.255) OPTIONAL, 


-- Timing Advance 


as per 


3GPP 


TS 3 6 


.321 


measRes 


,ultListEUTRA MeasResultLi 


3tEUTRA OPTIONAL, 










MeasResultListEUTRA 


::= SEQUENCE (SIZE (1 . .maxCellReport ) ) OF 


SEQUENCE 


{ 


physicalCellldenti 


ty INTEGER (0. .504) , 










globalCell Identity 


BIT STRING(SIZE (29)) OPTIONAL, -- 


inc 


Ludes 


the 


CSG bit 
















earf cn- 


DL INTEGER (0.. 32767), 


-- as per 3GPP TS 


36 .331 








measRes 


,ultEUTRA SEQUENCE { 












rsrpResult INTEGER 


(0. .97) OPTIONAL 


--as per 3GPP 


TS 36.331 






rsrqResult INTEGER 
•■•} 
} 


(0 . .33) OPTIONAL 


--as per 3GPP 


TS 36.331 







The IE "MeasResultListEUTRA" mirrors the equivalent IE from the RRC specification: 
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MeasResultEUTRA : : = SEQUENCE { 






physCellld 


PhysCellld, 




cgi-Info 


SEQUENCE { 




cellGloballd 


CellGloballdEUTRA, 




trackingAreaCode 


TrackingAreaCode , 




plmn-IdentityList 


PLMN-IdentityList2 


OPTIONAL 


} 


OPTIONAL, 




measResult 


SEQUENCE { 




rsrpResult 


RSRP- Range 


OPTIONAL, 


rsrqResult 

} 
} 


RSRQ-Range 


OPTIONAL, 



It should be noted that in addition to the container provided by SUPL itself, any E-CID positioning methods defined 
within LPP proper can be supported in SUPL, via tunneling LPP as shown in this annex (in the same manner that A- 
GNSS and OTDOA are supported). 



B.2 SUPL 2.0 and LTE Architecure 

This section describes interworking between the control-plane LCS architecture, as defined in the main body of this 
specification, and SUPL 2.0. The E-SMLC either includes or has an interface to an SPC function as defined in OMA 
SUPL V2.0 ([17], [18]). It can thus provide a consistent set of positioning methods for deployments utilizing both 
control-plane and user -plane. 

The interworking does not enable use of user-plane signalling for part of a control-plane positioning session. The user 
plane in the interworking here is not intended as an alternative path for control-plane signalling that would be needed 
between UE and eNodeB for mechanisms such as A-GPS in a standalone C-plane solution. 

This interworking does enable the SPC to retrieve measurements (e.g., GNSS-to-RAN time relations) from eNodeB. 

The underlying architecture is shown in Figure B.2-L Note that, for interworking between user -plane and control-plane 
positioning, no new interfaces need to be defined as compared to those in the figure, assuming the SPC is either 
integrated in the E-SMLC or attached to it with a proprietary interface. 



HSS 




LTE-Uu 



— Signaling 
_ TDatar 

06Mfiiction via 

intermediate 

IVIoaified 

Interface 
New^_ 

interfac^^ 

Non-LCS Entity 





SI-IVIIVIE 



MME 



GMLC 



SLg 



SLs 



E- 
SMLC 



- SPC 



Lip 



Serving 
Gatewa 

y 



S5 



PDN 
Gatewa 

y SGI 



Le 



LCS 
Client 



Lup 



Figure B.2-1: System architecture underlying positioning 

The Lup and Lip interfaces shown in this architecture are part of the user-plane solution only and are not required for 
control-plane positioning. The SLs interface is required for both control-plane and user -plane positioning, and needs to 
be capable of querying eNode Bs for information not related to a UE connection. 



ETSI 



3GPP TS 36.305 version 10.1.0 Release 10 



49 



ETSI TS 136 305 VI 0.1.0 (2011-04) 



SUPL, including the use of LPP over SUPL, takes place as part of the general user-plane protocol stack shown in Figure 
B.2-2. SUPL occupies the application layer in the stack, with LPP (or another positioning protocol) transported as 
another layer above SUPL. 



Application 



IP 



PDCP 



RLC 



MAC 



L1 



PDCP 



RLC 



MAC 



LI 



GTP-U 



UDP/IP 



L2 



LI 



Relay 

gtp-uTgtp-u 



UDP/IP 



L2 



L1 



UDP/IP 



L2 



L1 



IP 



GTP-U 



UDP/IP 



L2 



LI 



LTE-Uu S1-U S5/S8 SGI 

UE eNodeB Serving GW PDN GW 



Figure B.2-2: User-plane protocol stack 



B.3 LPP session procedures using SUPL 

This section indicates how an LPP session relates to the SUPL structure. Figure B.3-1 shows how SUPL and LPP can 
be combined within a SUPL positioning session. Step 4 here is repeated to exchange multiple LPP messages between 
the SLP and SET. 



SLR 



SET 



1.SUPLINIT 



2 Establish secure TCP/IP Connection 



3. SUPL POS INIT (E-CID measurements) 



4. SUPL POS (LPP PDU) 



5. SUPL END 



Figure B.3-1 : LPP session over SUPL 

For positioning operations which take place entirely within an LPP session (step 4 in Figure x.3), the flow of LPP 
messages can be the same as in the control-plane version of LPP; the role of the (LPP) target is taken by the target SET, 
and that of the (LPP) server by the SLP. An example LPP flow, including exchange of capabilities, request and delivery 
of assistance data, and request and delivery of positioning information, is shown in Figure B.3-2. 
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LPP Target 
(Target SET) 



LPP Server 
(SLP) 



— 1. LPP PDU: Location information request [position estimate, transaction A]-^ 

< 2. LPP PDU: Capability request [transaction B] 

3. LPP PDU: Capability indication [transaction B] ► 



4. LPP PDU: Assistance data request [transaction C]- 
-5. LPP PDU: Assistance data delivery [transaction C]- 



-6. LPP PDU: Location information request [measurements, transaction D] 

7. LPP PDU: Location information [measurements, transaction D] ► 



-8. LPP PDU: Location information [position estimate, transaction A]- 



Figure B.3-2: LPP session over SUPL 



B.4 Procedures combining C-plane and U-plane 
operations 

Since SUPL is by definition carried over the user plane, it is not really applicable to operations terminating at the eNode 
B. Thus, in some cases where information from the eNode B and UE needs to be merged for a positioning operation, 
SUPL operations must take place in combination with control-plane procedures over LPPa. 

This situation could arise in the case of UE-assisted OTDOA, for example, in which the SLP needs to provide the UE 
(in a SUPL session) with assistance data supplied by various eNode Bs. This section uses a UE-assisted OTDOA 
positioning operation as a running example. 

Although the positioning server in this operation is of course the SLP, the existence of the Lip interface means that the 
SLP can communicate freely with the E-SMLC via the SPC. In particular, this means that assistance data that were 
delivered to the E-SMLC via LPPa can be transferred over to the SLP for delivery to the UE via LPP over SUPL. 

Several ways to realise this general behaviour are possible. In the simplest case, the E-SMLC could be supplied with 
the necessary assistance data in advance, so that they can be supplied to the SLP without any actual LPPa procedures 
taking place in real time (and possibly even before the positioning transaction begins). 
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UE (SET) 



eNode B 



E-SMLC 



Assistance data_ 
(via LPPa) 



SLP 



SUPL session establishment 



Assistance data_ 
(via LPP/SUPL) 



Assistance data (via Lip) 



Figure B.4-1 : Transfer of OTDOA assistance data to UE via SUPL 

In the event that the E-SMLC does not have the required assistance data available, however, it would need to retrieve 
them from appropriate eNode Bs once it was made aware that they were needed. 



eNode B 




E-SMLC 



SLP 



SUPL session establishment 



Assistance data request_ 
via LPP/SUPL) 



Assistance data request_ 
(via LPPa) 



Assistance data_ 
(via LPPa) 



Assistance data request_ 
(via Lip) 



Assistance data_ 
(via Lip) 



Assistance data_ 
via LPP/SUPL)" 



Figure B.4-2: Transfer to the UE via SUPL of OTDOA assistance data not already available at the E- 

SMLC 

In both cases, it should be noted that the retrieval of the assistance data is transparent to the UE and to the actual SUPL 
session. This model is parallel to the approach used with A-GNSS, in which assistance data such as satellite 
ephemerides are retrieved from sources entirely external to the cellular network. For purposes of LP? over SUPL, the 
delivery of assistance data to the SLP can be looked on as an independent external process. 

The delivery of assistance data to the UE, however, takes place through the same mechanisms as control-plane LPP, 
transported through SUPL. 
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